src/main/java/com/ryu/studyhelper/solve/service/SolveService.java (2)

81-135: getDailySolved 로직이 깔끔하게 구성되어 있습니다.

LinkedHashMap으로 날짜 순서를 보장하고, 빈 날짜를 먼저 초기화하여 모든 날짜가 응답에 포함되도록 하는 설계가 좋습니다.

한 가지 사소한 개선 제안: Line 49의 member.getHandle().isEmpty() 대신 isBlank()를 사용하면 공백 문자만 있는 핸들도 방어할 수 있습니다.

♻️ 제안

-        if (member.getHandle() == null || member.getHandle().isEmpty()) {
+        if (member.getHandle() == null || member.getHandle().isBlank()) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/ryu/studyhelper/solve/service/SolveService.java` around
lines 81 - 135, Replace usages of member.getHandle().isEmpty() with
member.getHandle().isBlank() to also treat strings containing only whitespace as
empty; locate the check (currently using isEmpty) where member handles are
validated and update it to isBlank(), ensuring any logic that depends on an
empty handle (e.g., in getDailySolved-related user formatting or display flows)
continues to behave the same after the change.

---

147-156: getAdjustedDate가 TeamActivityService.getMissionDate와 중복됩니다.

두 메서드 모두 "오전 6시 기준 날짜 보정" 로직을 구현하고 있습니다. 현재는 기능적으로 동일하지만 독립적으로 관리되므로 향후 한쪽만 수정될 위험이 있습니다. 추후 공통 유틸리티 클래스로 추출하는 것을 검토해 주세요.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/ryu/studyhelper/solve/service/SolveService.java` around
lines 147 - 156, getAdjustedDate duplicates logic in
TeamActivityService.getMissionDate; extract the shared "06:00 기준 날짜 보정" into a
single utility method (e.g., MissionDateUtils.adjustToMissionDate(LocalDateTime)
or DateUtils.getMissionDate) and update both SolveService.getAdjustedDate and
TeamActivityService.getMissionDate to call that util (or remove the duplicate
method and replace callers with the util). Ensure the util accepts
LocalDateTime, performs the same hour < 6 -> minusDays(1) rule, and update
imports/usages so both SolveService and TeamActivityService delegate to that
common method.

src/main/java/com/ryu/studyhelper/team/service/TeamActivityService.java (1)

154-181: assignRanks 로직이 RankingService와 중복됩니다.

TeamActivityService.assignRanks (Lines 154-181)와 RankingService.assignRanks (Lines 37-64)의 순위 부여 알고리즘이 동일한 패턴을 사용하고 있습니다. 입력/출력 타입(MemberSolvedSummaryProjection vs GlobalRankingProjection)만 다릅니다.

PR 목표에 후속 작업으로 언급되어 있지만, 추후 공통 유틸리티 메서드로 추출하거나 제네릭/함수형 인터페이스를 활용하여 통합하는 것을 권장합니다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/ryu/studyhelper/team/service/TeamActivityService.java`
around lines 154 - 181, The rank-assignment loop in
TeamActivityService.assignRanks duplicates the logic in
RankingService.assignRanks; extract the common algorithm into a shared utility
(e.g., RankingUtils.assignRanks or a generic RankAssigner<T>) that accepts a
list of projections and a mapper function to produce memberId, handle and
solved-count, then return List<TeamActivityResponse.MemberRank> (or a generic
rank DTO) and call that utility from both TeamActivityService.assignRanks and
RankingService.assignRanks; reference MemberSolvedSummaryProjection,
GlobalRankingProjection, TeamActivityResponse.MemberRank and the assignRanks
methods to locate where to replace the duplicated loop with the shared generic
utility.

src/main/java/com/ryu/studyhelper/solve/repository/MemberSolvedProblemRepository.java (1)

25-26: 메서드 이름이 매우 깁니다 — @Query로 전환을 고려해 보세요.

findByMemberIdAndSolvedAtGreaterThanEqualAndSolvedAtLessThanOrderBySolvedAtAsc는 가독성이 낮습니다. 명시적 @Query 어노테이션과 짧은 메서드 이름(findByMemberIdAndSolvedAtRange 등)으로 대체하면 가독성이 크게 개선됩니다.

♻️ 제안

-    List<MemberSolvedProblem> findByMemberIdAndSolvedAtGreaterThanEqualAndSolvedAtLessThanOrderBySolvedAtAsc(
-            Long memberId, LocalDateTime start, LocalDateTime end);
+    `@Query`("SELECT msp FROM MemberSolvedProblem msp WHERE msp.member.id = :memberId AND msp.solvedAt >= :start AND msp.solvedAt < :end ORDER BY msp.solvedAt ASC")
+    List<MemberSolvedProblem> findByMemberIdAndSolvedAtRange(
+            `@Param`("memberId") Long memberId,
+            `@Param`("start") LocalDateTime start,
+            `@Param`("end") LocalDateTime end);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/ryu/studyhelper/solve/repository/MemberSolvedProblemRepository.java`
around lines 25 - 26, Replace the overly long derived query method
findByMemberIdAndSolvedAtGreaterThanEqualAndSolvedAtLessThanOrderBySolvedAtAsc
in the MemberSolvedProblemRepository with a concise method name (e.g.,
findByMemberIdAndSolvedAtRange) and annotate it with `@Query` containing the
equivalent JPQL (select m from MemberSolvedProblem m where m.member.id =
:memberId and m.solvedAt >= :start and m.solvedAt < :end order by m.solvedAt
asc); keep the parameter types (Long memberId, LocalDateTime start,
LocalDateTime end) and ensure you add the `@Param` annotations or matching
parameter names to the query so the repository still returns
List<MemberSolvedProblem>.

src/test/java/com/ryu/studyhelper/solve/service/SolveServiceTest.java (2)

218-250: 리포지토리 호출 시 any() 매처 사용으로 날짜 범위 파라미터 검증이 누락되어 있습니다.

findByMemberIdAndSolvedAtGreaterThanEqual... 호출에 any() 매처만 사용하고 있어, 실제로 올바른 날짜 범위가 전달되는지 검증하지 않습니다. 예를 들어 Line 230의 solved2는 15:00인데 Clock은 14:00으로 고정되어 있어 실제 서비스에서는 조회 범위 밖일 수 있습니다.

ArgumentCaptor를 사용해 전달되는 날짜 범위 파라미터도 검증하면 테스트 신뢰도가 높아집니다. 이 부분은 후속 개선 사항으로 고려해 주세요.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/test/java/com/ryu/studyhelper/solve/service/SolveServiceTest.java` around
lines 218 - 250, The repository call in the test uses any() for the date range
so the test doesn't verify the actual time window passed into
memberSolvedProblemRepository.findByMemberIdAndSolvedAtGreaterThanEqualAndSolvedAtLessThanOrderBySolvedAtAsc;
add ArgumentCaptor<LocalDateTime> (or two captors) to capture the start and end
parameters when invoking solveServiceWithClock.getDailySolved(1L, 7) and assert
they match the expected range based on the fixed clock (e.g., start =
clock.now().minusDays(6).atStartOfDay, end =
clock.now().plusDays(1).atStartOfDay or equivalent used by the service), keeping
the mocked return values for solved1/solved2 but verifying that the later
solved2 (15:00) falls inside/outside the captured range as intended.

---

39-53: @InjectMocks로 생성된 solveService에 Clock이 null로 주입됩니다.

SolveService 생성자는 Clock을 필요로 하지만, 외부 클래스 레벨에는 Clock에 대한 @Mock이 없습니다. Mockito @InjectMocks는 매칭되는 mock이 없으면 null을 주입합니다. 현재 VerifyProblemSolvedTest에서는 Clock을 사용하지 않아 동작하지만, 향후 solveService로 getDailySolved를 호출하면 NullPointerException이 발생합니다.

외부 클래스에도 Clock mock을 추가하거나, VerifyProblemSolvedTest처럼 명시적으로 SolveService를 생성하는 방식으로 통일하는 것을 권장합니다.

♻️ 제안: 외부 클래스에 Clock mock 추가

     `@Mock`
     private SolvedAcClient solvedAcClient;
 
+    `@Mock`
+    private Clock clock;
+
     private Member member;
     private Problem problem;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/test/java/com/ryu/studyhelper/solve/service/SolveServiceTest.java` around
lines 39 - 53, The SolveService instance created with `@InjectMocks` is receiving
a null Clock because there is no Clock mock declared; add a `@Mock` Clock clock to
the test class (or alternatively stop using `@InjectMocks` and instantiate
SolveService explicitly like in VerifyProblemSolvedTest) so Mockito can inject a
non-null Clock into the SolveService constructor and avoid NullPointerException
when calling methods like getDailySolved; update references to SolveService,
`@InjectMocks`, Clock, and getDailySolved accordingly.

src/test/java/com/ryu/studyhelper/solve/service/SolveServiceTest.java (1)

217-218: 내부 클래스의 Clock mock이 외부 클래스 필드를 섀도잉합니다.

GetDailySolvedTest의 @Mock Clock clock이 외부 클래스(line 54-55)의 동일한 필드명을 숨기고 있습니다. Mockito가 @Nested 클래스의 mock을 별도로 초기화하므로 동작에는 문제없지만, 필드명을 testClock 등으로 변경하면 가독성이 향상됩니다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/test/java/com/ryu/studyhelper/solve/service/SolveServiceTest.java` around
lines 217 - 218, The nested test class GetDailySolvedTest declares a `@Mock` Clock
clock that shadows the outer class's Clock field; rename the nested mock (e.g.,
to testClock) and update all references inside GetDailySolvedTest to use that
new name so there is no field shadowing; modify the `@Mock` declaration in
GetDailySolvedTest, and update any setup/when/verify calls inside
GetDailySolvedTest that currently reference clock to use testClock (leave the
outer Clock field and its usages untouched).